Amazon RDS が意図せず再起動!!その時あなたはどうする!?
「Amazon RDS が意図せず再起動したら、どうやって原因究明したら良いんだろう?」
ってお悩みではありませんか?今回は当該事象発生時に私が確認しているポイントを紹介したいと思います。
それでは早速やっていくっ!
確認ポイント
以下の7つを確認します!(確認の順番は適宜入れ替えてください)
- AWS Service Health Dashboard
- AWS Personal Health Dashboard
- 対象 RDS のメンテナンスタブ
- 対象 RDS の最近のイベント
- 対象 RDS の error ログ
- CloudTrail
- CloudWatch
1. AWS Service Health Dashboard
Amazon Web Services publishes our most up-to-the-minute information on service availability in the table below.
AWS Service Health Dashboard (以降、SHD )では上記の通り、AWS サービスの可用性に関する最新情報を公開しています。こちらのページを参照することで、AWS サービス毎の状態を俯瞰的に確認して、AWS サービス自体に問題が発生していないか確認することが可能です。
If you are experiencing a real-time, operational issue with one of our services that is not described below, please inform us by clicking on the "Contact Us" link to submit a service issue report.
上記の通り、必ずしもサービスで発生してる問題の全てが記載される訳ではないようなので注意しましょう。
2. AWS Personal Health Dashboard
AWS Personal Health Dashboard – 関係するリソースの管理
Service Health Dashboard は AWS の サービスの全般的なステータスを表示しますが、Personal Health Dashboard では、ご利用の AWS リソースの基礎となる AWS のサービスのパフォーマンスおよび可用性に関するパーソナライズされた表示を利用できます。
AWS Personal Health Dashboard(以降、PHD)では、SHD より自分の AWS 環境に沿った情報が表示されます。こちらのページを参照することで、自身のリソース固有の問題が発生していないか確認することができます。SHD と同様に必ずしもサービスで発生してる問題の全てが記載される訳ではない印象なので注意しましょう。
3. 対象 RDS のメンテナンスタブ
Amazon RDS では、Amazon RDS リソースのメンテナンスを定期的に実行します。通常、メンテナンスには DB インスタンスの基盤となるオペレーティングシステム (OS) やデータベースエンジンのバージョンの更新が伴います。
運用者がうっかり忘れてたということは少ないかと思いますが、こちらのページを参照することで、対象のクラスターとインスタンスの定期的なメンテナンスが影響していないか確認することが可能です。
4. 対象 RDS の最近のイベント
AWS マネジメントコンソールを使用して RDS リソースのイベントを取得し、過去 24 時間のイベントを確認できます。(中略) AWS CLI または RDS API を使用してイベントを表示する場合は、最大で過去 14 日間のイベントを取得できます。
障害発生時間が24時間以内の場合は、こちらのページを参照することで、障害の原因となるイベントがないか確認することが可能です。障害発生時刻が24時間以上前の場合は、 【小ネタ】RDSイベントは直近1日分しか表示されないのでAWS CLIで確認しよう を参考にしてイベントを確認してみてください。
5. 対象 RDS の error ログ
エンジンによって error ログの仕様が異なるので、上記リンクを参照してご利用のエンジンの発生時刻周辺の error ログを確認しましょう。私はざっくり以下のように確認しています。
- Shutdown のログの前に何かしらのエラーが出ている:エラー内容をGoogleで検索して確認
- Shutdown のログの前に何かしらのエラーが出ていない:AWS 基盤側の問題?
6. CloudTrail
CloudTrail コンソールで CloudTrail イベントを表示する
CloudTrail のイベント履歴で、対象 RDS のリソース名でフィルタして、発生時刻周辺のユーザ操作を確認します。こちらのページを参照することで、人為的な操作が問題でないか確認することが可能です。
7. CloudWatch
CloudWatch メトリクスで、対象 RDS のリソース名でフィルタして、ストレージ容量や CPU 使用率などを確認します。こちらのページを参照することで、キャパシティ不足や突発的な重たい処理が原因でないか確認することが可能です。
上記を調べても分からない場合は?
原因が分からない場合や AWS 基盤側の問題が疑われる場合は、Support Center から問合せしましょう。弊社メンバーズポータルをご利用の場合は、弊社の専用フォームよりお問い合わせください。
AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。
尚、問合せ時に発生事象とこれまでの調査内容を整理して共有いただくと早期解決に役立ちます。上記の公式ガイドラインにも問い合せ時のポイントが書いてあるので是非ご一読ください。
まとめ
RDSが意図せず再起動したら、以下を確認してみましょう!
- AWS Service Health Dashboard
- AWS Personal Health Dashboard
- 対象 RDS のメンテナンスタブ
- 対象 RDS の最近のイベント
- 対象 RDS の error ログ
- CloudTrail
- CloudWatch
サポートに問い合わせする時は、早期解決の為に、 技術的なお問い合わせに関するガイドライン を参照して問い合わせしよう!
最後に
いかがだったでしょうか。障害の切り分けの方法は人それぞれかと思います。ただ確認ポイントが整理されていると安心かなと思い、私なりに整理してみました。
また今回は紹介しませんでしたが、問題発生時にサービスへの影響を最小限にする設計はとても重要です。 AWSにおける可用性の考え方 を理解して、 Amazon RDS での高可用性 (マルチ AZ) なども是非検討ください。
以上!筧( @TakaakiKakei )でした!
更新履歴
- 2019/12/19 新規作成